NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/2695

Internet Message Format | 1996-08-05 | 5.7 KB

Path: newshost.lanl.gov!tanmoy
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.lang.c,gnu.gcc.help
Subject: Re: [Q] WEIRD macro bug only when compiling with GCC
Date: 23 Jan 1996 06:19:12 GMT
Organization: Los Alamos National Laboratory
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
    <[e-mail]>
NNTP-Posting-Host: qcd.lanl.gov
Mime-Version: 1.0
Content-Type: text
In-reply-to: [e-mail]'s message of Tue, 23 Jan 1996 04:24:22 GMT

--text follows this line--

(I mailed this to the poster because he mailed his post to me ... this
copy is for others following the thread. It is already too long, so I
do not quote the original in detail).


Your mistake is in assuming there is a order among the operands of the
+ operation; I had stated (as you correctly quote):

>a=c and c*c. However as the + operator does not enforce _any_ order
>(not even the existence of an order) between its two operands, there
>is no sequence point _between_ a=b and a=c.

Look at the part in parenthesis! So, what I meant to say (and as has
been discussed quite often in the comp.std.c forum) is that what is
guaranteed is that in (a=b,b*b) + (a=c,c*c) (I choose the easier case
to describe, replace b*b and c*c by a*a consistently throughout and
everything still stands correct):

The side effects of a=b will be done before the b*b
The side effects of a=c will be done before the c*c

No other statement about side effects can be made! Note that
parentheses enforce absolutely _no_ requirement on side effects: in
particular, there is no requirement that (a=b,b*b) be done as one
unit; before _or_ after (a=c,c*c). In discussions in comp.std.c, this
is called `interleaved' evaluation. Thus a possible order of
evaluation is

a=b
a=c
b*b
c*c

Hope that explains the exact meaning of sequence points. Now to
discuss a few more of your statements:

 > Right about the sequence points. I could see that this would be a
 > problem if I had something like (a=b) + (a=c).  Then the program sets
 > a=b, but right after sets a to c, so it would yield 2*c (or 2*b if the
 > compiler first evaluated the right hand side of the + operator).  *But*

This is wrong! It could equally well yield zero or 42 as well. The
behaviour is called `undefined' which means that the standard does not
put any constraints on the compiler trying to compile your
program. Imagine that a hardware needs 2 stores to store an int
(e.g. when the data bus is 8bit wide and ints are 16). It could chose
to store the bytes and evaluate in the following order

low  order byte of b into low  order byte of a
low  order byte of c into low  order byte of a
high order byte of b into high order byte of a
high order byte of c into high order byte of a
evaluate a+a in the standard fashion

Note that now you get neither 2*c nor 2*b. Such optimizations were
meant to be allowed, and so when the standard says somethig is
undefined, treat it _precisely_ as that. In fact, on exotic enough
hardware, the program can core dump on a signal of simultaneous memory
update signal (made up example).

 > here, the result a*a must be stored in some place independent from a,
 > say a register or some memory location.  The 2 sides of the + operator
 > are evaluated independently (ie there is no precedence problem between
 > the + and = and comma), and the comma *is* a sequence point with forced
 > order from left to right.  Therefore when the program evaluates (a=b,
 > a*a) (or the other side of the + operator just revert the conclusion
 > which follows), if first evaluates b, stores it in a, then does a*a and
 > stores the result somewhere in memory.  Then it evaluates c, stores it
 > in a (even if a is now changed, it doesn't change the first a*a, since
 > that is a stored result somewhere in memory), evaluates a*a, and should
 > store it somewhere *else* in memory, then adds the contents of those 2
 > memory locations.  So, there should be no problem.  There is no

As I mentioned before, you are assuming that either the left or the
right side of the + is evaluated in its entirety before the other side
starts. There is no reason why this must be so. (For example, if the
compiler knows that you have two cpus it can use one to calculate the
lhs of + and the other to calculate the rhs. Where will the ordering
come from?)

 > ambiguity about say, doing first a=b, then a=c, and only after that
 > doing a*a and again a*a, because of the parentheses.  Or, why would GCC
 > store the two results (from each side of the + operator) in the same
 > memory location, just because a*a occurs on both sides of the + operand?
 >

It does not.

 > >problem mentioned above, but in addition there is no sequence point
 > >between the a=c and the first a*a (likewise between the a=b and the
 > >second a*a).
 >
 > You must mean something else here, since you just said (and I checked),
 > that the comma is a sequence point, and not only that, its order is
 > specified.
 >

The comma is a sequence point, but only between _its_ first and second
operands. It says that its left operand is evaluated completely (along
with side effects) _before_ its right operand: it does _not_ say that
nothing else can happen in the middle.

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]